nat46-core: Drop packet with non-IPv4-translatable IPv6 address #10
Conversation
RFC6145 Section 5.2 discussed about non-IPv4-translatable IPv6 addresses on the IPv6 headers, and left the solution for stateless translation as future work. RFC6791 has recommendations for this issue, but until that's implemented, silently drop the packet.
|
Which problem does this solve ? When implementing this, I found that putting in a bogus address helps recover more problematic situation than just dropping the packet. |
|
Hi, the decision to silently drop the packet was based on RFC792, which did not require or made it mandatory to send ICMP error messages. RFC6791 Section 3.1 also stated that the "source address used should not cause the ICMP packet to be discarded". This happened in our scenario, where the receiver of the ICMP packet discarded it. But I'm very interested to know of these problematic situations you mentioned. Maybe our system hasn't encountered those scenarios yet. I would appreciate if you can provide details on these problematic situations. Thanks. |
|
The two scenarios I remember about (alas it was probably 10 years ago :) were the PMTUD and traceroute when debugging. |
RFC6145 Section 5.2 discussed about non-IPv4-translatable
IPv6 addresses on the IPv6 headers, and left the solution
for stateless translation as future work. RFC6791 has
recommendations for this issue, but until that's implemented,
silently drop the packet.